This PR implements basic validation for start, stop, tol, and
widths.

When invalid input is encountered an exception will be thrown.

Specifically, a InvalidArgumentException is thrown detailing the error
state that has occurred.

We debated whether or not to throw exceptions in a few cases;
ultimately we have decided that error states should be clearly
defined and handled (both for us internally and for users).

What this means is that, in a few cases, our library will throw
which results in callers being immediately alerted of the error
state that caused the exception to be thrown (so that errors are
not propagated silently throughout application code).

This is an added layer of safety to help ensure code that depends
on this library remains correct (w.r.t. it's usage of this library).

In short, the validation we are doing here says that callers:

• cannot define negative image widths
• cannot define invalid width ranges, e.g. start > stop
• cannot define invalid width tolerance values, e.g. 0.00001

We consider these constraints to be reasonable and empowering
rather than limiting. That is, this kind of validation helps guard
against typos, e.g.